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Background 


The  goal  of  this  pilot  project  was  to  determine  the  feasibility  of  and  requirements  for  a  systems  engineering 
capstone  experience  marketplace  environment.  We  hope  to  increase  the  number  of  systems  engineering 
capstone  projects  conducted  at  universities  each  year  by  facilitating  the  cooperation  and  coordination  of  teams  of 
students  from  multiple  campuses  on  individual  projects.  This  has  the  potential  for  increasing  student  engagement, 
as  it  enables  student  participation  at  schools  that  might  not  otherwise  have  the  faculty  interest  or  resources  to 
undertake  such  projects.  It  also  makes  it  easier  to  conduct  projects  of  greater  size  and  complexity  where  the 
benefits  of  a  systems  engineering  approach  are  more  visible. 

The  program  was  implemented  in  three  sequential  phases  over  a  12-month  period: 

During  Phase  1/Startup  (September  1,  2012-January  31,  2013)  the  software  for  the  marketplace  registry  was 
prepared,  candidate  projects  were  entered  into  the  registry,  students  entered  their  qualifications  into  the 
registry,  students  volunteered  for  projects,  project  teams  were  created,  and  projects  were  started. 

During  Phase  2/Project  Completion  (February  1,  2013-June  30,  2013)  student  projects  completed  their  work  and 
submitted  final  deliverables  to  stakeholders,  and  stakeholders  and  faculty  performed  assessments  of  student 
work. 

During  Phase  3/Guideline  Preparation  (July  1,  2013-August  31,  2013)  all  participating  faculty  distilled  the  lessons 
of  the  distributed  team  and  prepared  guidelines  for  future  instances  of  the  marketplace,  and  suggested 
modifications  were  made  to  the  marketplace  software. 
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Phase  1/Startup  Experience 


This  section  of  the  report  summarizes  progress  made  during  the  first  phase  of  the  project. 


Participating  Sponsors  and  Projects 

Project  ideas  and  potential  sponsors  for  student  projects  were  found  through  a  combination  of  search  strategies: 
sponsors  and  mentors  of  capstone  projects  at  RT-19  and  RT-19A  participating  institutions,  candidate  leads 
suggested  by  SERC  researchers,  national  laboratory  contacts  suggested  by  members  of  the  OASD(R&E)  STEM 
Development  Office,  and  personal  networking. 

Although  there  was  little  time  to  prepare  project  proposals,  9  separate  projects  were  collected  and  presented  to 
student  participants  through  the  registry  website: 


Sponsor 

Project 

Advertising.com 

Mobile  advertising  effectiveness 

FAA 

Airport  operation  and  safety 

Lincoln  Laboratory 

Mobile  communication  system  for  crisis  situations 

NASA 

*Water  vapor  radiometer  for  a  satellite 

US  Army 

*Monitoring  subsystem  for  a  training  system 

US  Navy 

*Safe,  affordable  ferry  for  transportation  in  a  developing  country 

US  Navy 

*Components  for  a  disaster  relief  kit 

US  Navy 

Power  generator  using  energy  from  coastal  waves 

Videology 

Video  advertising  forecasting  capabilities 

The  projects  annotated  with  leading  asterisks  were  selected  by  student  teams.  Two  of  those  projects,  the  ferry  for 
a  developing  country  and  the  components  for  a  disaster  relief  kit,  were  merged  into  one  project.  The  monitoring 
subsystem  project  was  executed  by  multiple  teams  in  parallel. 

This  list  was  more  than  adequate  to  satisfy  student  needs,  as  all  participating  students  were  able  to  find  projects 
of  interest.  Several  other  project  leads  were  pursued  that  did  not  yield  proposals  in  time  for  the  pilot  but  that  may 
lead  to  projects  in  future  years. 
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Participating  Schools 


Participation  in  this  pilot  project  was  limited  to  schools  that  had  already  participated  in  RT-19  or  RT-19A,  or  were 
members  of  the  SERC.  An  invitation  to  join  the  pilot  was  distributed  to  all  of  those  schools,  and  several  follow-up 
communications  were  made  to  promote  interest  and  participation. 

5  schools  joined  the  project: 


School 

Students 

Missouri  University  of  Science 
and  Technology  (MUST) 

36  graduate  students  in  systems  engineering  on  8  separate 
teams 

Southern  Methodist 

University  (SMU) 

3  undergraduate  students  in  electrical  engineering 

4  undergraduate  students  in  computer  science 

Stevens  Institute  of 

Technology 

4  undergraduates  in  engineering  management 

2  undergraduate  students  in  naval  engineering 

University  of  Alabama  in 
Huntsville  (UAH) 

4  undergraduates  in  aerospace  engineering 

University  of  Hawaii  at  Manoa 

4  graduate  students  in  information  technology 

Many  potential  candidate  schools  and  departments  reported  that  it  was  already  too  late  to  consider  participation 
by  the  time  they  were  contacted.  Nevertheless,  the  5  schools  that  did  join  provided  a  variety  of  institution  types 
and  partnership  arrangements.  Several  schools  responded  with  interest  in  participating  in  a  marketplace  system 
in  future  years. 

Some  schools  start  creating  teams  during  the  spring  semester,  some  do  it  over  the  summer,  and  some  schools 
have  to  wait  until  the  fall  term  when  students  come  back  to  campus.  So  the  window  needs  to  open  during  the 
spring  academic  term  (before  April)  and  close  at  the  start  of  the  fall  term  (September  15).  Ideally,  some  project 
opportunities  would  be  identified  as  early  as  January. 


Experience  with  Website  Registry  System 

The  software  for  the  website  registry  was  adapted  from  a  system  developed  at  Stevens  Institute  by  a  previous 
student  capstone  team.  That  system  was  designed  to  allow  students  to  form  multidisciplinary  teams  through  self¬ 
selection:  students  volunteered  for  proposed  projects  posted  on  the  website,  faculty  supervisors  reviewed  those 
student  applications  and  approved  project  participation.  There  were  mechanisms  in  place  for  students  to  post 
comments  on  proposed  projects  and  for  new  projects  to  be  proposed  by  faculty  or  students. 
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Some  of  the  features  of  the  original  system  were  specific  to  the  Stevens  environment.  For  example,  in  preparing 
their  personal  profiles  students  selected  their  academic  major  from  a  list  of  majors  available  at  Stevens.  This  same 
list  was  used  to  allow  project  proposers  to  specify  types  of  needed  students.  Security  and  access  to  the  website 
assumed  that  all  users  would  be  members  of  the  Stevens  community  and  would  have  accounts  on  the  Stevens 
computing  network.  All  of  these  features  were  removed  or  adapted  for  use  by  a  wider  community. 


The  resulting  system  provided  facilities  to  display  project  proposals  and  to  register  students.  Instead  of  a  web- 
based  profile  entry  system  students  were  asked  to  fill  out  a  form  that  they  uploaded.  The  principal  investigator 
had  the  ability  to  see  all  the  project  choices  that  students  made,  but  students,  faculty  and  sponsors  were  only 
allowed  to  see  the  project  proposals. 

Students  used  the  system  to  find  projects.  The  project  descriptions  were  short  text  narratives  without  any 
graphics,  but  with  pointers  to  other  websites  with  more  information  in  some  cases.  Since  students  were  not  able 
to  see  whether  other  students  had  already  selected  projects,  we  did  not  get  a  chance  to  test  whether  that  would 
have  influenced  their  choices.  We  also  did  not  test  the  capability  for  project  sponsors  to  review  and  approve 
student  applicants.  Instead,  faculty  at  each  school  reviewed  their  student  applicants. 


Team  Formation 

Student  teams  were  formed  in  different  ways.  At  two  schools  faculty  selected  projects  and  assigned  students  to 
teams.  At  two  other  schools  students  were  allowed  to  choose  their  own  projects.  In  all  cases  faculty  were 
involved  in  final  selection  of  projects  and  team  members.  At  Stevens  two  teams  were  initially  formed  to  work  on 
independent  projects.  Faculty  then  realized  that  the  two  teams  would  work  more  effectively  on  a  combined 
project.  A  team  from  the  University  of  Alabama  in  Fluntsville  also  joined  the  same  project. 

As  mentioned  earlier,  we  were  not  able  to  test  students'  ability  to  form  teams  independently  through  the  website 
registry  system.  Instead  faculty  guided  or  assisted  students  in  the  formation  of  teams.  This  is  an  expense  (in 
effort)  that  we  hope  to  reduce  in  the  future  through  the  marketplace  system.  Part  of  the  expense  is  the  effort 
required  to  collect  information  from  the  students  (e.g.,  interests  and  abilities,  preferences  for  other  teammates). 
Another  part  is  matching  students  to  teams  and  then  dealing  with  complaints/problems  that  require  switching 
assignments.  Depending  on  the  school,  these  two  processes  can  consume  many  hours  distributed  over  a  couple 
months.  It  is  not  so  much  the  total  time  involved  that  matters,  but  the  nuisance  of  dealing  with  a  noisy  process. 
Letting  the  students  form  their  own  teams  eliminates  much  of  this,  though  there  will  always  be  some  team¬ 
forming  problems  that  faculty  will  need  to  solve.  Letting  students  form  their  own  teams  also  encourages  them  to 
accept  responsibility  for  their  own  problems.  We  want  engineering  students  to  learn  some  of  the  organizational 
and  social  skills  involved  in  this  process. 
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Student  TEAM  progress 


Each  of  the  student  teams  made  good  progress  in  their  first  semester.  Although  almost  all  of  the  teams  started 
later  than  they  had  originally  intended,  they  all  made  up  lost  time  and/or  re-scoped  their  projects  to  be  on 
schedule.  In  some  cases  teams  were  held  up  by  delays  or  changes  in  funding  that  caused  them  to  rescale  their 
projects.  Each  of  the  projects  used  good  systems  engineering  practices. 


Student  interaction  between  teams 

Some  of  the  student  teams  had  frequent  contact  with  one  another,  while  others  did  not.  The  team  from  the 
University  of  Hawaii  had  originally  intended  to  work  with  both  the  SMU  team  and  the  MUST  team.  Neither  of 
those  partnerships  developed.  The  Stevens  and  UAH  teams  were  in  constant  contact  throughout  the  first 
semester.  They  met  weekly  by  Skype  and  exchanged  email  regularly. 
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Phase  2/Project  Completion 


This  section  of  the  report  summarizes  progress  made  during  the  second  phase  of  the  project. 


NASA  Water  vapor  radiometer  project 

This  project  engaged  1  team  of  students  from  SMU:  3  undergraduate  students  in  eiectricai  engineering  and 
4  undergraduate  students  in  computer  science.  The  team  successfuiiy  designed  a  virtuai  radiometer  to  meet  the 
stated  needs  of  NASA  for  their  CHARM  (CubeSat  Hydrometric  Atmospheric  Radiometer  Moduie)  project. 

The  team  had  originaiiy  pianned  to  coiiaborate  with  a  team  of  students  at  the  University  of  Hawaii  at  Manoa,  but 
that  coiiaboration  never  materiaiized  for  at  ieast  2  reasons: 

1.  Our  Co-Pi  at  SMU  was  assigned  a  different  course  to  teach  just  before  the  faii  semester  started,  and  a 
substitute  instructor  was  assigned  to  the  student  team  for  their  capstone  course.  The  new  instructor  was 
ieery  of  adding  the  burden  of  working  with  a  distant  team  to  the  project. 

2.  The  SMU  team  discovered  that  their  avaiiabie  budget  was  significantiy  iower  than  they  had  anticipated, 
causing  them  to  re-scope  their  project  and  redefine  the  requirements.  They  worked  hard  to  compiete 
their  tasks  for  a  preiiminary  design  review  in  October.  Once  that  was  passed  they  were  reiuctant  to  risk 
their  project  scheduie  again  by  collaborating  with  an  unknown  team. 

The  team  produced  a  testable  prototype,  prepared  a  final  report  and  gave  a  presentation  to  their  faculty 
supervisor.  Although  some  good  systems  engineering  practices  were  followed  by  this  project,  some  aspects  of  risk 
management  and  iterative  system  development  were  not.  It  would  have  been  helpful  to  provide  more  tutorial 
material  for  new  instructors,  such  as  the  one  assigned  to  this  team. 


Army  Monitoring  subsystem  for  a  training  system 

This  project  engaged  8  sub-teams  of  36  graduate  students  in  systems  engineering  at  MUST.  The  student  teams 
collaborated  in  the  design  of  a  control  system  for  a  wireless  immersive  training  vest  monitoring  system.  Most  of 
the  students  were  part-time  distance  students  scattered  throughout  North  America,  but  a  few  were  full-time 
students  on  the  campus  at  MUST. 

Originally  the  sub-team  at  the  University  of  Hawaii  at  Manoa  had  planned  to  work  with  the  students  at  MUST,  but 
they  were  unable  to  find  a  place  to  contribute.  The  MUST  students  did  not  feel  that  they  had  enough  time  in  their 
schedule  to  include  a  separate  Verification  and  Validation  effort.  Part  of  their  concern  was  the  need  to  develop 
software  for  the  monitoring  system,  an  area  where  the  MUST  students  were  weak. 

The  sub-teams  collaborated  in  the  production  of  a  testable  prototype.  They  also  produced  final  reports  and  gave 
presentations  to  their  faculty  supervisors.  All  of  the  MUST  sub-teams  used  good  systems  engineering  practices, 
including  design  reviews  and  overall  lifecycle  activities.  Their  course  includes  a  classroom  component  that  teaches 
the  basics  of  systems  engineering  each  term.  Additionally,  many  of  the  students  were  experienced  engineers  who 
had  practiced  systems  engineering  in  their  jobs.  This  course  and  project  helped  to  solidify  their  understanding  and 
appreciation  of  the  field. 
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Navy  Dual-Use  Ferry/HADR  Kit  project 

This  project  engaged  3  sub-teams  of  students:  a  team  of  4  aerospace  engineering  students  at  UAH,  a  team  of  2 
undergraduate  naval  engineering  students  at  Stevens,  and  a  team  of  4  engineering  management  students  at 
Stevens. 

The  naval  engineering  students  from  Stevens  designed  a  ferry  for  use  in  developing  countries,  such  as  Bangladesh, 
where  ferry  traffic  is  common.  Unfortunately,  many  of  the  current  ferries  capsize  in  bad  weather  due  to  poor 
design  for  local  conditions  and  lax  operating  procedures,  especially  overcrowding.  The  design  proposed  by  the 
naval  engineering  students  has  much  greater  stability  than  current  vessels,  and  is  better  suited  for  the  type  of 
river  navigation  required.  Additionally,  the  ferry  design  allows  it  to  transport  emergency  supplies  when  needed. 

The  aerospace  students  from  UAH  designed  a  water  purification  system  that  could  be  transported  in  a  Joint 
Modular  Intermodal  Container  (JMIC).  They  constructed  a  prototype  system  that  demonstrated  the  feasibility  of 
their  design,  including  meeting  space  constraints  and  providing  adequate  interfaces.  They  also  conducted  an 
analysis  of  the  volume  of  water  that  could  be  treated  using  their  solar  and  battery  powered  system.  Given 
adequate  sunlight,  their  system  could  provide  clean  water  for  a  small  village  for  several  days. 

The  engineering  management  students  from  Stevens  provided  overall  management  of  the  project,  including  risk 
management  and  resource  scheduling.  They  also  conducted  research  to  develop  complete  requirements  for  the 
project.  One  of  the  project  mentors  provided  a  contact  in  Bangladesh  that  the  Stevens  student  team  contacted  to 
determine  several  important  parameters  about  river  conditions,  ferry  traffic  and  social  customs  of  the  area. 

The  student  sub-teams  met  with  one  another  by  teleconference  to  exchange  information  and  discuss  plans.  The 
Stevens  engineering  management  sub-team  communicated  with  the  project  sponsor,  relaying  information  to  and 
from  the  other  sub-teams.  At  the  end  of  the  project  all  of  the  students  and  their  faculty  advisors  met  with  the 
project  sponsor  and  mentors  at  the  Stevens  campus  in  Washington,  DC.  At  that  meeting  the  students  displayed 
their  prototype  HADR  kit  and  demonstrated  its  feasibility.  The  combined  teams  gave  a  presentation  to  the 
sponsor,  the  mentors  and  the  faculty.  Each  team  also  prepared  a  final  report. 

Each  of  the  sub-teams  followed  good  systems  engineering  practices,  including  design  reviews.  The  UAH  team  met 
with  their  instructor  each  week  where  they  had  a  chance  to  discuss  systems  engineering  concepts,  and  they  were 
given  a  template  schedule  adapted  from  NASA's  guidebook  on  systems  engineering. 
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Phase  3/Guideline  Preparation 


This  section  of  the  report  summarizes  progress  made  during  the  third  phase  of  the  project. 

The  originai  pian  had  been  to  conduct  a  workshop  with  aii  of  the  facuity  instructors  at  the  end  of  the  academic 
year  to  discuss  iessons  iearned.  However,  it  was  not  possibie  to  find  a  time  when  aii  of  the  facuity  couid  meet,  so 
the  Pi  exchanged  emaii  with  them  individuaiiy  and  foiiowed  up  by  phone  and  personai  contact.  For  the  Navy  Duai- 
Use  Ferry/HADR  Kit  project  the  Pi  met  by  Webex  with  aii  facuity  invoived. 

Severai  usefui  iessons  iearned  were  distiiied  from  these  conversations.  They  are  reported  in  the  next  section. 
Additionaiiy,  a  recommended  tempiate  scheduie  for  muitidiscipiinary  systems  engineering  capstone  projects  was 
created.  The  scheduie  shouid  provide  sufficient  guidance  to  instructors  to  ensure  that  students  use  good  systems 
engineering  practices  throughout  their  projects.  The  tempiate  aiso  provides  fiexibiiity  for  additionai  requirements 
to  be  added  to  meet  program-specific  needs.  For  exampie,  programs  that  need  to  perform  extensive  verification 
and  vaiidation  activities  on  prototype  soiutions  may  inciude  that  in  their  scheduies. 

A  new  marketpiace  website  was  created  in  response  to  some  of  the  iessons  iearned  from  the  use  of  the  piiot 
system.  The  new  system  was  deveioped  with  more  robust  technoiogy  and  is  much  easier  to  use  from  the  systems 
administration  side.  Some  of  the  improvements  made  inciude: 

•  an  executive  summary  of  the  capstone  marketpiace  project  on  the  front  page 

•  a  Frequentiy  Asked  Questions  (FAQ)  page  for  students  and  facuity 

•  a  sponsor-provided  graphic  for  each  project  proposai 

•  a  standard  format  for  proposai  descriptions 

•  oniine  forms  for  student  and  facuity  appiications 


Lessons  Learned  and  Recommendations 


This  section  provides  recommendations  for  future  efforts  in  this  area. 


Enlisting  Participants 

Capstone  projects  are  soiicited  and  defined  in  the  spring  semester  at  many  schoois.  Some  academic  programs  try 
to  have  aii  their  students  assigned  to  teams  before  they  ieave  campus  for  the  summer,  in  some  cases  projects 
actuaiiy  start  with  student  internships  that  take  piace  during  the  summer  before  the  senior  year,  if  the 
marketpiace  hopes  to  compete  within  this  environment  it  must  have  projects  ready  for  review  and  seiection  by 
Aprii  at  the  iatest,  but  even  eariier  wouid  be  better.  We  hope  to  have  some  projects  avaiiabie  for  review  in 
January  this  coming  year. 

Before  making  proposais,  project  sponsors  need  to  consider  issues  of  inteiiectuai  property,  avaiiabie  resources  to 
support  student  teams,  and  scope  of  potentiai  projects.  Exampies  of  past  projects,  inciuding  proposais, 
inteiiectuai  property  agreements,  project  scheduies  and  finai  presentation  materiais  wouid  be  of  great  heip  to 
potentiai  project  sponsors.  These  same  artifacts  are  aiso  an  aid  to  students  and  facuity  in  pianning  and  starting 
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new  projects.  The  website  registry  should  have  a  collection  of  these  artifacts  for  review  and  adaptation  by  other 
projects.  There  is  a  place  designed  for  this  in  the  new  website  system,  but  we  do  not  yet  have  any  artifacts  except 
a  template  schedule.  We  plan  on  providing  several  of  these  artifacts  over  the  next  academic  year.  We  also  plan  to 
include  some  results  from  the  pilot  student  teams. 


Website  Registry  System 

We  were  fortunate  to  have  an  existing  web-based  system  that  had  many  of  the  features  we  needed  for  our 
website  registry.  Modifying  that  software  was  the  only  feasible  strategy  we  had  when  the  pilot  started.  However, 
the  software  proved  to  be  quite  fragile  and  difficult  to  modify  for  our  use.  It  was,  after  all,  only  a  prototype 
constructed  by  a  small  team  of  students.  In  order  to  have  a  trustworthy  system  to  use  in  the  future  we  needed  to 
create  a  new  version  from  a  fresh  start. 

Some  proposed  features  of  the  registry  system  were  not  available  in  the  pilot  project,  and  they  are  still  not  yet 
available  in  the  new  system.  For  example,  students  are  not  able  to  record  comments  about  projects  or  potential 
teammates  in  the  registry.  Sponsors  are  not  able  to  view  student  applicants  to  their  projects.  These  features 
should  be  implemented  and  tested  in  a  future  version  of  the  registry. 


Team  Formation 

Although  the  marketplace  concept  allows  for  participation  by  individual  students  at  different  schools  it  is  much 
easier  to  engage  sub-teams  of  students,  where  each  sub-team  is  co-located  and  supervised  by  a  common  faculty 
member.  This  fits  more  easily  with  existing  faculty-student  teaching  relationships,  and  it  provides  more  security 
and  robustness  in  student  interactions.  Teams  of  sub-teams  also  allow  for  larger  projects,  which  are  more  realistic 
examples  of  multidisciplinary  systems  engineering. 


Funding 

The  marketplace  concept  allows  for  multiple  types  of  projects  and  sponsors.  Some  sponsors  are  able  to  provide 
funding  for  student  materials  and  supplies,  while  others  are  not.  Student  teams  need  to  know  their  budget  before 
starting,  and  their  school  contracting  offices  need  to  have  agreements  on  hand  at  the  start  of  the  fall  term,  even 
though  most  student  teams  will  not  be  ready  to  spend  their  funds  until  the  spring  academic  term. 


Project  engagement  and  cooperation 

Project  planning  and  initiation  are  crucial  to  the  success  of  these  projects.  Especially  in  cases  where  teams  from 
different  schools  collaborate  it  would  be  best  if  faculty  (and  other  stakeholders)  met  before  the  project  starts  to 
prepare  for  a  kickoff  meeting  of  the  students.  They  should  decide  what  type  of  collaboration  is  needed,  and  agree 
on  expectations  of  each  sub-team. 
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Faculty  should  point  out  to  students  that  collaborative  projects  are  more  challenging,  but  they  are  also  good 
learning  experiences.  Lessons  they  learn  will  translate  to  useful  points  on  their  resumes  and  stories  to  tell  during 
job  interviews.  Faculty  should  also  explain  team  dynamics  to  students  and  remind  them  about  those  during  the 
project. 

The  students  should  meet  one  another  at  a  kickoff  meeting  of  all  team  members.  A  face-to-face  meeting  would  be 
ideal,  or  a  video  virtual  meeting  could  be  held.  During  the  meeting  the  stakeholders  (or  faculty)  can  present  the 
problem  and  some  expected  results.  Students  can  volunteer  for  roles,  and  faculty  can  help  set  expectations  for 
sub-team  responsibilities.  After  the  meeting  each  sub-team  should  share  their  summary  of  their  understanding  of 
the  results  of  the  meeting,  including  their  expected  roles  and  responsibilities,  with  other  sub-teams. 

During  the  project  each  sub-team  should  meet  at  least  weekly,  and  each  sub-team  should  communicate  with 
other  sub-teams  at  least  weekly.  Each  sub-team  may  elect  to  assign  a  communication  role  to  a  liaison  member  of 
their  sub-team  to  simplify  communication  between  sub-teams  and  mentors.  Gantt  charts  and  timelines  for  sub¬ 
team  tasks  are  useful  artifacts  for  sub-teams  to  share  during  the  project. 

A  mid-term  review  and  a  final  review  should  be  held  with  the  whole  team  each  academic  semester.  These  are 
good  opportunities  to  involve  the  stakeholders  and  mentors.  Students  should  be  reminded  that  they  need  to 
meet  their  deadlines,  even  though  their  products  may  not  always  be  perfect. 


Role  of  client  and  mentors 

Interaction  with  clients,  mentors  and  other  stakeholders  is  an  important  part  of  the  capstone  experience.  Regular 
meetings  should  be  scheduled,  perhaps  monthly,  to  ensure  that  students  have  some  minimal  level  of  interaction. 
Stakeholders  should  be  invited  to  all  reviews. 


Role  of  faculty 

Faculty  should  meet  regularly  with  their  teams,  especially  at  the  beginning  and  end  of  each  term.  A  weekly 
schedule  is  best.  During  these  meetings  students  can  report  status,  report  current  challenges  and  share  proposed 
solutions  to  problems. 


Student  experience  and  learning 

Collaborative  projects  provide  a  more  realistic  experience  for  students,  and  they  offer  more  opportunities  for 
students  to  observe  and  apply  systems  engineering  techniques.  The  extra  challenges  encountered  with 
communication  and  coordination  are  balanced  by  the  extra  benefits  of  learning  offered  by  these  projects. 
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Recommended  template  schedule 


The  following  table  shows  the  expectations  of  multidisciplinary  systems  engineering  capstone  projects.  We 
assume  that  each  project  is  two  semesters  long.  Dividing  each  semester  in  half  produces  4  half-terms  of  equal 
length. 


Time  Period 

Activity 

Deliverable 

First  half-term 

Stakeholder  identification 

List  of  stakeholders  and  their 
expected  roles 

First  half-term 

Problem  identification 

Problem  statement 

First  half-term 

Risk  identification 

Description  of  potential  project 
risks 

First  half-term 

Project  planning 

Preliminary  project  plan 

Second  half-term 

Requirements  analysis 

Requirements  specification 

Second  half-term 

Market  study 

Description  of  competing  or 
enabling  products 

Second  and  third  half-terms 

Design  exploration 

Ranked  list  of  alternative  designs 

Third  half-term 

Design  specification 

Description  of  proposed  design 
solution 

Third  and  fourth  half-terms 

Design  implementation 

Prototype  solution 

Fourth  half-term 

Presentation  preparation 

Demonstration  of  prototype 

Fourth  half-term 

Project  reflection 

Final  report  of  project 

Each  project  should  have  at  least  4  reviews: 


Time  Period 

Review 

Participants 

End  first  half-term 

Preliminary  Project  Plan 

Faculty  and  students 

End  first  semester 

System  Requirements 

All  stakeholders 

Third  half-term 

Preliminary  Design  (if  possible) 

Key  stakeholders 

End  third  half-term 

Critical  Design 

Key  stakeholders 

End  second  semester 

Project  Conclusion 

All  stakeholders 

Some  projects  may  choose  to  include  other  activities,  deliverables  and  reviews.  For  example,  some  projects  may 
create  a  CONORS  during  the  requirements  analysis  phase,  while  others  may  perform  tests  and  evaluations  of  their 
prototype  solutions  at  the  end  of  the  project.  Similarly,  some  projects  may  choose  to  include  more  participants  in 
their  reviews  than  the  minimum  list  suggested  above. 
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Conclusion 


As  expected,  we  were  more  successful  in  some  areas  than  in  others  on  this  pilot  project.  Given  the  late  start  in 
acquiring  project  proposals  and  engaging  students  and  faculty,  we  still  learned  quite  a  bit  from  the  project. 

The  pilot  was  successful  in: 

•  finding  several  good  projects  and  sponsors 

•  providing  a  registry  website  for  students  to  review  project  proposals  and  to  post  their  qualifications 

•  creating  an  interesting  3-way  collaboration  on  one  project 

Faculty  and  students  made  good  use  of  the  registry  website  to  find  projects.  In  some  cases  students  found 
projects  on  their  own,  while  in  other  cases  faculty  selected  projects  or  guided  students  in  their  selection. 

The  pilot  was  unsuccessful  in: 

•  allowing  students  to  form  their  own  teams  through  discovery  on  the  website  registry 

•  providing  funding  to  all  schools  when  they  needed  it 

•  creating  collaborations  between  teams  for  all  students 

Some  of  these  goals  may  be  met  by  improving  the  website,  others  by  engaging  sponsors  and  participating  schools 
earlier  in  the  year.  The  schools  need  a  budget  to  give  to  students  at  the  beginning  of  the  fall  term  (September  15). 
Whether  or  not  that  means  a  subcontract  is  in  place  varies  from  school  to  school. 

Faculty  provided  good  advice  in  planning  and  conducting  future  multidisciplinary  systems  engineering  capstone 
projects.  This  advice  should  be  condensed  into  a  form  to  post  on  the  marketplace  website  for  potential  student 
and  faculty  participants.  Some  other  useful  artifacts  still  need  to  be  collected  or  created  for  posting  to  the 
website. 
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